Thanks — the friction this addresses is real (agents do try react({ emoji: '👍' }) first). Two changes here with very different risk profiles; please split.

readReactionMessageId — ready to merge (after split). Falling back to toolContext.currentMessageId is clean. SDK type checks out, precedence is right (messageId > message_id > fallback), tests cover the three branches.

Alias map — silent regression that CI didn't catch. Two entries in FEISHU_REACTION_ALIASES collide with canonical Feishu types that are already valid and in use:

['clap',  'APPLAUSE']   // `CLAP` ≠ `APPLAUSE` in Feishu (both valid, different emojis)
['heart', 'LOVE']       // `HEART` ≠ `LOVE`     in Feishu (both valid, different emojis)

The case-insensitive lookup (MAP.get(normalized) ?? MAP.get(normalized.toLowerCase()) ?? normalized) silently rewrites canonical uppercase type names at runtime:

normalizeReactionEmoji('HEART') -> 'LOVE'      ⚠️
normalizeReactionEmoji('CLAP')  -> 'APPLAUSE'  ⚠️

There's no existing test exercising 'HEART' or 'CLAP' through normalizeReactionEmoji. The new 'MUSCLE' passthrough test only works because there's no muscle collision. So CI stays green even though any agent passing FeishuEmoji.HEART or FeishuEmoji.CLAP (canonical names already exported from src/messaging/outbound/reactions.ts) would post a different emoji after this merges.

Recommended fix: move aliasing to the tool schema, not code. The reason agents pass '👍' is the tool's emoji field description doesn't tell them what shape to use. The right place to teach the model is the schema, not a runtime alias map. It teaches once (the model sees the schema on every tool call and learns the canonical shape upfront, no validation-error round-trip), stays in sync automatically (VALID_FEISHU_EMOJI_TYPES is the authoritative list sourced from official Feishu docs and the schema description can reference it directly), keeps the typed contract honest (type stored = type passed, no hidden rewrites for future readers to chase), and rules out this regression class entirely (schema documentation can't silently rewrite caller input). Concretely, extend the emoji field description with something like "Feishu reaction type name (e.g. THUMBSUP, LAUGH, HEART, LOVE). See the full list in VALID_FEISHU_EMOJI_TYPES. Emoji unicode like 👍/+1 is not accepted — use the canonical type name."

Fallback (only if schema-layer isn't enough). If you have a trace showing the model keeps passing '👍' even after the description is updated, code-layer aliasing becomes justified. In that case, scope it to emoji unicode → canonical type only (drop word aliases like thumbsup/heart/clap — those collide) and gate on "not already in VALID_FEISHU_EMOJI_TYPES" so that if a value is already canonical it returns as-is and skips the map. This eliminates the regression class entirely and makes the contract explicit ("we only translate emoji unicode, never canonical names").

Action items. First, split this PR — readReactionMessageId + its 3 tests can ship as a standalone PR, and I'll approve and merge it as soon as the split lands. Second, for the alias half, update the tool schema description first; reopen with code-layer aliasing only if there's evidence schema docs aren't sufficient.

Re-reading this against the SDK surface — openclaw/plugin-sdk/channel-actions already exports resolveReactionMessageId, which does readStringOrNumberParam(args, 'messageId') ?? toolContext?.currentMessageId. The SDK's own Discord and Signal channel adapters use it directly; Feishu is the outlier. The self-rolled readReactionMessageId here both duplicates the SDK and drifts from it (string-only vs string|number).

Note the SDK reader already accepts snake_case automatically — readStringOrNumberParam(args, 'messageId') will pick up args.message_id via readSnakeCaseParamRaw. So the explicit message_id branch and its test add no behavior over the SDK helper.

Please switch handleReact / handleReactions to the SDK helper, match the Discord/Signal pattern (String(...) cast, throw with "messageId required. Provide messageId explicitly or react to the current inbound message."), and drop tests/reaction-defaults.test.ts — the helper is owned and tested by the SDK now.